Secure Java Class Loading

W hen Java technology burst onto the Internet scene in 1995, its developers declared the ambitious goal of providing a safe programming environment, especially for Web-based, dynamically composed, and mobile applications.1,2 OEM vendors and licensees could port the Java platform to their environment, such as browsers and operating systems, and inherit extensive built-in security features. Java’s security tools and services enabled independent software vendors to build a wider range of security-sensitive applications—for example, in the enterprise world—with minimal effort. Java’s original security model for these tools and services is known as the sandbox model. This model features a very restricted environment in which to run untrusted code (called applets) obtained from the open network.3 Essentially, the sandbox model trusts local code to have full access to vital system resources, such as the file system. However, the model does not trust downloaded remote code, so restricts its access to only a small set of limited resources. The Java Development Toolkit, versions 1.0.x, deploy this sandbox model, as do most applications built with JDK, including Java-enabled Web browsers. For more about the sandbox model, see the sidebar “The Mechanisms of Java Sandbox Security.” To extend the sandbox model, Sun Microsystems introduced signed applets with JDK 1.1.x in early 1997. In this model, Java treats a correctly digitally signed applet as trusted local code, if the end system that receives the applet recognizes the signature key as trusted. Developers deliver signed applets, together with their signatures, in the Java Archive format. In this article, I describe the more finely grained, permission-based access control architecture, and its relation to the class loading mechanism, that will be available in the JDK 1.2 release.